The present invention relates generally to the field of computer resource management, and in particular to a CPU power monitor for use in analyzing the power efficiency of software running on a computer. The invention is particularly well-suited for monitoring CPU power management in battery-powered, mobile personal computer systems (i.e., notebook or laptop PCs).
Designers of mobile PCs are faced with two apparently-conflicting user requirements: desktop PC equivalence and long battery life. To help meet these requirements, system designers go to great lengths to maximize the power conservation capabilities of mobile computers. Practically every device in these systems has some level of power management capability, including hard disk drives, displays and communication ports.
Historically, the central processing unit (CPU) has been a key contributor to power consumption and heat generation in mobile computers. Chip manufacturers, such as Intel Corporation, have therefore incorporated power management features into their CPUs, such as "stop clock" and "halt" states. This technology allows a tradeoff between high performance and power/heat conservation. For example, a Pentium.RTM.90 processor running the Windows.RTM.95 operating system draws approximately 6-7 watts when operating at full capacity; however, when Windows.RTM.95 is idle and the CPU is primarily in a halt state, consumption drops to just 1 watt.
Unfortunately, even with the sophisticated power management techniques now employed, higher processor speeds and state-of-the-art hardware such as Advanced Graphics Ports and DVD drives will likely cause mobile PCs to reach their maximum thermal dissipation limit (i.e., approximately 20 watts) within the next few years. To make matters worse, battery technology has tended to improve at a much slower rate than the increasing power requirements of mobile PCs, resulting in shortened battery life. Additional ways of conserving power must therefore be found to help combat these trends.
To date, efforts at improving PC power management have virtually ignored software; however, software may be the simplest area in which to gain back "wasted" watts and reduce system heat. Software is indirectly a power consumer by keeping hardware, most notably the CPU, busy. Indeed, poorly-written software can actually waste several watts while providing the user with no tangible benefit. Well-behaved software conserves power by minimizing CPU utilization without any user-perceptible degradation in performance.
In a Windows.RTM.95 environment, for example, a primary way in which power-wise software reduces unnecessary CPU use is by avoiding polling loops while waiting for user input, hardware events or software semaphores. Well-behaved software gives up control to the operating system during these times, and only periodically examines the state of the device, event or semaphore of interest. As a general rule, an application should draw more than minimal power only when providing some user-perceptible benefit (e.g., recalculating a spreadsheet, repaginating a word processing document, displaying an MPEG movie).
Unfortunately, many of today's popular software titles have been found to be power-wasting applications. This has a significant impact on system power consumption, since just one errant application will spoil the system's ability to perform power management. Moreover, computer users cannot readily detect power-wasting applications. Unbeknownst to system users, their favorite applications may be depleting their batteries unnecessarily, severely limiting run time.
A properly architected, power-friendly application should not adversely impact performance on either a desktop PC or a mobile system. From a development standpoint, it does not take much more effort to create a power-friendly application than one that wastes power, but the resulting power savings and reduction in heat generation can be substantial. Using a single, well-designed product for both environments will result in quality applications that run well on all systems.
The CPU power monitor of the present invention is intended to encourage and assist software developers to create software that is both effective and mobile PC-friendly. Using this invention, software vendors can test software on both desktops and mobile computers to ensure they deliver an efficient and power-friendly product.
The present invention is primarily, but not exclusively, directed to a Windows.RTM.95 operating environment. It is thus beneficial to understand how Windows.RTM.95 currently handles power management in order to better appreciate the benefits and advantages of the present invention.
Power management in the Windows.RTM.95 environment is done cooperatively between three layers of software, as shown in FIG. 2. At the bottom-most software level is the APM (Advanced Power Management) BIOS, which controls power to the various system hardware components (e.g., hard disk, chipset, CPU). Just above the BIOS level is the Windows.RTM.95 operating system itself. At the top of the software stack are the various applications running on the system.
The APM BIOS provides a system-independent interface for performing power management on computer systems-employing an Intel.RTM. Architecture. The specific way in which computer systems handle APM calls will vary among system implementations. For example, the APM BIOS may handle certain built-in devices such as the video monitor differently from platform to platform. The APM BIOS specification intentionally avoids defining how to perform power management at the device level, in favor of abstractly allowing a power driver to request various device-directed power activities.
Among the APM BIOS' specified functions is the CPU.sub.-- Idle API (Application Program Interface) call, which allows the CPU to be placed into a low-power state. The APM BIOS normally does this by executing an HLT instruction, which turns off some of the internal circuitry of the CPU until the next external interrupt. On an idle Windows.RTM.95 system, the HLT instruction is executed about once every 13.7 ms and the CPU remains in a low-power state approximately 98% of the time.
While executing HLT is the usual method for saving processor power, several CPU chipsets provide support for other power-saving mechanisms, such as "Stop Clock." The APM BIOS specification allows the BIOS vendor to tailor functionality to a particular platform.
The Windows.RTM.95 power driver, "VPOWERD.VXD," supplies a means of communication between the APM BIOS and the operating system. This power driver is integrated into the core VMM.VxD driver. VPOWERD exports several APIs which give the operating system access to the power-saving features of the APM BIOS, including the above-mentioned CPU.sub.-- Idle call. Whenever Windows.RTM.95 detects that all loaded software, drivers, and the operating system itself are idle, Windows.RTM.95 makes a CPU.sub.-- Idle call via VPOWERD. By this call, the operating system is said to be in the idle state and has given control to the APM BIOS to save power.
Applications usually do not participate directly in power management activities, although methods do exist within Windows.RTM.95 by which software may play a more active role in that regard. Applications can nevertheless have a significant impact on the operating system's ability to enter the idle state, because the operating system cannot enter that state until all loaded software is idle.
For an application to enter the idle state, it must voluntarily give control back to the operating system. This is normally done by calling a Windows.RTM. blocking API, such as GetMessage or WaitMessage. Calls to these APIs tell the operating system to return only when the application has more messages or events to process. On the other hand, there are certain Windows.RTM. APIs that do not enter this blocking state, such as PeekMessage. Such APIs return to the calling application immediately whether or not there is a message waiting. Under these circumstances, Windows.RTM.95 believes that the application has more processing to do and will not enter the idle state. This allows the application to have full use of the CPU until the application calls one of the blocking APIs or is preempted by the operating system.
Once all applications have entered their idle state, Windows.RTM.95 gives the virtual device drivers (VxD) in the system the opportunity to perform any necessary idle processing. To provide this opportunity, the VMM (Virtual Machine Manager) driver will call a list of pre-registered VxD idle callback addresses, know as the "idle callback chain." If a VxD wants to prevent the system from idling, it returns from the idle callback with its carry flag clear. This act of preventing idle is called "consuming idle" or "eating idle." If, on the other hand, the VxD returns with its carry flag set, the operating system knows that, at least as far as that particular VxD is concerned, it is permissible for the system to enter the idle state. When all the VxDs in the idle callback chain are idle (i.e., return with carry flag set), VPOWERD calls the CPU.sub.-- Idle APM BIOS function to conserve power.
It is important to note that under certain operating systems, most notably Windows.RTM.95, one individual application or VxD has the ability to contravene attempts by all the other applications and drivers to facilitate power management. In other words, a single application that blocks power management activity will sabotage power management for the entire system. While all other applications may be waiting for an input or an event, the single non-idle application will be scheduled to run. The operating system will only enter the idle state when all applications and VxDs are idle.
In view of the dramatic negative impact even one poorly-written application can have on a system's power management efficiency, a significant purpose of the CPU power monitor according to the present invention is to determine when software is preventing the system from entering an idle state and, more specifically, to determine which application is causing the problem.